Modern data processing systems are becoming increasing modular. The systems are configured so that users may select a system that meets their processing and memory needs. For example, the ES7000 system commercially available from Unisys Corporation may be configured to allow users to add up to 32 processors to the system, based on their individual requirements. These processors need not all be of the same type. For example, some of the processors may be selected from those commercially available from the Unisys Corporation, while others are selected from those commercially available from Intel Corporation. As these processors are added to the system, additional cache memories and processor interfaces must also be included within the system. Additional memory may also be added in predetermined increments. Input/Output units and mass storage may further be included. This approach allows a user to tailor a system to their specific needs.
Modular systems are beneficial from a marketing standpoint. The same system architecture can be used to support a large number of product offerings. However, from a design and development standpoint, these types of systems provide special challenges. Each system configuration must be analyzed to ensure proper operation. Additionally, performance characteristics of the various configurations must be determined. Optimally, this type of analysis will be performed while the system is still in the design phase so that design problems may be more easily addressed.
One way to perform performance analysis is using a performance analysis tool. Such tools have been developed to provide performance data for an associated data processing system. Some of these tools use queuing equations to model the system. For example, a set of equations may be developed to model the latency associated with a given type of request to memory. These equations will take into account the minimum latency governed by intrinsic propagation delays, and will also take into consideration queuing times that are affected by the amount of request traffic within the system. The intrinsic propagation delays are affected by system parameters such as clock, bus, processor, and memory speeds. Other examples of variables that can affect the intrinsic delays include memory size, the number of instruction and I/O processors within the system, and the existence and size of various cache memories within the system.
Prior art performance tools of the type discussed above receive as an input a single comprehensive model that provides all of the parameter values necessary to perform the analysis. This model provides values for all system variables, including request levels, clock and bus speeds, and the size and/or type of some or all of the components (e.g., memories and processors) within the system. These values are entered into the queuing equations so that latency of the various paths within the system can be determined, and throughput may be calculated.
The performance analysis technique described above is generally an iterative process. For example, if a system designer wants to compare a current system configuration to another configuration, the designer creates another copy of the current model, and changes one or more parameters. For instance, the designer may create a second model that includes a larger main memory. This model can be saved, and the queuing equations can be re-evaluated so that latency and system throughput values are obtained for the second model. These values can then be compared to those for the first model.
The prior art mechanism discussed in the foregoing paragraphs has its drawbacks. As discussed, the models may be very large, particularly where large-scale data processing systems are concerned. For this reason, a large amount of storage space may be consumed to store multiple models. If many models are needed to complete an exhaustive study of all possible system configurations, the storage space required for this effort may become prohibitive. However, if the models are not saved after a particular analysis is performed, they may need to be re-created later if some aspect of the study must be re-performed. This can be very time-consuming. Additionally, evaluation of performance data is generally performed during a manual process that compares the latency and throughput data of one model to one or more other models. This manual comparison is tedious and error prone.
Another example of a performance analysis tool is disclosed in U.S. Pat. No. 6,311,175 to Adriaans et al. The Adriaans system and method involves automatically creating performance models of complex information technology (IT) systems. System components are periodically monitored to determine performance thresholds. A continuity analysis is then performed by synchronizing testing functions associated with the predetermined system performance thresholds. Data obtained from this analysis is used to develop models of the system that may be used to analyze system performance for another configuration of the system.
The Adriaans approach monitors an existing system to develop a performance model. The model may then be used to approximate the performance of an alternative system configuration. Therefore, this method cannot be used unless a working configuration of the system in question exists. However, as discussed above, it is generally desirable to conduct some performance analysis on a data processing system while the system is still in the design stages so that problems can be more easily addressed. This cannot be accomplished using the Adriaans system.
U.S. Pat. Nos. 5,960,181 and 5,978,576, both to Sanadidi et al., describe a system for simulating the various aspects of massively parallel processors. The system includes a processor that executes a simulation program. The simulation program includes multiple software submodels, each simulating the operations of a respect aspect of the system. Data is passed between the submodels using procedure calls.
The system described by Sanadidi et al. is a complex software system that must be developed and tested. That is, each portion of the system under test is associated with a software component. The test software must be designed and tested in what may require a substantial development effort. In today's fast-paced environment, this type of significant effort may not be possible where a test vehicle is concerned, particularly when the focus is on getting the primary product (i.e., the data processing system) to market quickly.
Still another alternative approach is described in U.S. Pat. No. 6,266,804 B1 to Isman. In Isman, a graph is developed that describes the execution of a particular software application upon a particular parallel processing system. Based upon the graph and supplied numerical data that describes empirically determined details about the data processing system, an analysis is made concerning the performance of the particular software application running on the system.
Isman models the performance of a particular software application running on a particular hardware configuration. The Isman approach is not adapted to measure the performance of the data processing system alone. What is needed, therefore, is an improved system and method for analyzing the performance of various configurations of a data processing system.